home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9707 / 000010_owner-urn-ietf _Mon Jul 28 14:35:25 1997.msg < prev    next >
Internet Message Format  |  1997-07-31  |  3KB
  1. Received: (from daemon@localhost)
  2.     by services.bunyip.com (8.8.5/8.8.5) id OAA23669
  3.     for urn-ietf-out; Mon, 28 Jul 1997 14:35:25 -0400 (EDT)
  4. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
  5.     by services.bunyip.com (8.8.5/8.8.5) with ESMTP id OAA23660
  6.     for <urn-ietf@services.bunyip.com>; Mon, 28 Jul 1997 14:35:22 -0400 (EDT)
  7. Received: from marine.sonic.net (marine.sonic.net [208.201.224.37])
  8.     by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id OAA16996
  9.     for <urn-ietf@bunyip.com>; Mon, 28 Jul 1997 14:35:19 -0400 (EDT)
  10. Received: from sub.sonic.net (sub.sonic.net [208.201.224.8])
  11.           by marine.sonic.net (8.8.5/8.8.5) with ESMTP
  12.       id LAA14864 for <urn-ietf@bunyip.com>; Mon, 28 Jul 1997 11:36:53 -0700
  13. Received: from bolt.sonic.net (tallen@bolt.sonic.net [208.201.224.36]) by sub.sonic.net (8.8.5/8.8.5) with ESMTP id LAA14517 for <urn-ietf@bunyip.com>; Mon, 28 Jul 1997 11:35:04 -0700
  14. X-envelope-info: <tallen@bolt.sonic.net>
  15. Received: (from tallen@localhost) by bolt.sonic.net (8.8.5/8.7.3) id LAA14474 for urn-ietf@bunyip.com; Mon, 28 Jul 1997 11:36:30 -0700
  16. Date: Mon, 28 Jul 1997 11:36:30 -0700
  17. From: Terry Allen <tallen@sonic.net>
  18. Message-Id: <199707281836.LAA14474@bolt.sonic.net>
  19. To: urn-ietf@bunyip.com
  20. Subject: [URN] Re std-, prv-
  21. Sender: owner-urn-ietf@Bunyip.Com
  22. Precedence: bulk
  23. Reply-To: Terry Allen <tallen@sonic.net>
  24. Errors-To: owner-urn-ietf@Bunyip.Com
  25.  
  26. Leslie replying to Ron:
  27. | Is it also necessary/interesting to have a separate registry that simply
  28. | registers the namespace ID, without any connotations of accessibility
  29. | through one resolution system or another?    I.e., _just_ a registry
  30. | of known namespace ID's.
  31.  
  32. Someone is going to make a business of making a list of all known
  33. name space IDs (so as to be able to offer some sort of response to
  34. any request for any purported URN).  I don't know whether it's useful 
  35. to spend volunteer effort on doing so.
  36.  
  37. | > connotations. How about something like "r<digits>-", where the
  38. | > R stands for "registered" and the digits let us deal with multiple
  39. | > requests for a particular namespace ID? The ever-popular "foo"
  40. | > NID would have r1-foo, r2-foo, r3-foo, etc.   
  41. | 
  42. | And would the "r" number be dropped for namespaces that had gone through
  43. | the full standardization process?
  44.  
  45. Either way I'm confused.  Do we need to do this?  Why?  I didn't find
  46. a clear reason in the straw proposal.
  47.  
  48. | I'll accept Martin's argument for dropping the "std-" (although it
  49. | sounds suspiciously isomorphic to the "URL:/URN:" problem :-)  but 
  50. | I think it is important to be able to distinguish namespaces that have
  51. | _not_ gone through a standardization process.  So, if we did something
  52. | like the "r-" scheme, I would like to see that dropped for standardized
  53. | namespaces.
  54.  
  55. How about, standardized name space IDs are those registered in the
  56. appropriate registry, and all others are nonstandardized?
  57.  
  58.  
  59. Regards,
  60.   Terry Allen    Electronic Publishing Consultant    tallen[at]sonic.net
  61.                    http://www.sonic.net/~tallen/
  62.     Davenport and DocBook:  http://www.ora.com/davenport/index.html
  63.